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BACKGROUND OF THE INVENTION 



TECHNICAL FIELD 



The invention relates to application specific integrated circuits (ASICs). 
More particularly, the invention relates to a framework for reusable, run time 
configurable test benches for the verification of ASIC designs. 



maintenance of test benches has grown to become a disproportionately large part of the 
total design effort. In an ASIC verification engine, such as provided by VERILOG, test 
benches have become slow to compile and cumbersome to maintain. 



to write a single test bench that contains a number of tasks that exercise different 
aspects of the designs. Team members add new tasks as the verification effort 
continues, and tests are run by calling different sets of tasks in different order, 
depending on the functionality being tested. 

One problem with this approach is that the test bench must be recompiled 
for every new simulation. Even though compiled simulators offer features such as 



DESCRIPTION OF THE PRIOR ART 



As ASIC complexity keeps increasing, the time spent in design and 



The traditional approach to test bench development and ASIC verification is 
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incremental compilation, in which only the code that changed is recompiled, this still 
means that a lot of time is spent compiling test benches. 

Initial efforts to reduce this problem involved using configuration files. In 
this approach, one tries to make the test bench code to be all things to all people. Test 
5 benches typically contain complicated case statements and if-then-else sequences. 

These are controlled by parameters that are read from a text configuration file when the 
simulation is launched. 

This approach eliminates the need to recompile test benches repeatedly, but 
introduces an even worse problem, i.e. test benches become extremely complicated, 
10 very difficult to maintain, and very application specific. Often, when new functionality 
is added to a test bench, it has side effects that cause other tests to break. At the end of 
the project, one has a test bench that very few people understand, and that is so 
convoluted that there is no possibility of reuse. 

It would be advantageous to provide an approach to ASIC verification in 
15 which test benches do not become extremely complicated, very difficult to maintain, or 
very application specific. It would be of additional advantage in such approach if, when 
new functionality is added to a test bench, it does not introduce side effects that cause 
other tests to break. Further, at the end of the project, one should have a test bench that 
anyone can understand, and that is not so convoluted that there is no possibility of 
20 reuse. 



SUMMARY OF THE INVENTION 

A scripting approach to managing the test bench complexity issue is 
25 provided. Partitioning the functionality of a test bench between VERILOG and a 
scripting language allows for a significant reduction in compile times during ASIC 
verification. If done correctly, partitioning also offers great potential for re-use of test 
bench components. 

The Tel language was chosen as a basis for implementing a library of PLI 
30 routines that allow fully customizable interpreters to be instantiated in VERILOG test 
benches. This library allows multiple Tel interpreters to be instantiated in a VERILOG 
simulation. The Tel interpreters can interact with the simulation and cause tasks to be 
executed in the VERILOG simulation. 
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It has been found the TCL_PLI library is extremely valuable in speeding up 
verification efforts on multi-million gate ASICs. 



BRIEF DESCRIPTION OF THE DRAWINGS 

Figure 1 is a block schematic diagram that illustrates the required 
interaction between the VERILOG simulation and a Tel interpreter according to the 
invention. 



10 DETAILED DESCRIPTION OF THE INVENTION 

The invention provides a solution to the problem of providing a reusable test 
bench for ASIC design verification by making the configuration files more powerful, so 
that some of the complexity that is coded in VERILOG is shifted over to something that 
15 is evaluated at run time. In essence, a scripting language is provided that interacts with 
the simulation. 

With this approach, one can design a simple test bench which contains a 
number of tasks that handle low level interaction with the device under test. If these 
tasks are called from a scripting language, one can develop different verification scripts; 

20 each test tailored to verifying a specific aspect of the design. 

A key difference from the prior art configuration file approach is that the 
intelligence that determines the ordering of events is moved from VERELOG to a script 
file that is interpreted at run time. Different people can use the same test bench to test a 
design in completely different ways. They have the benefit of significantly reduced 

25 need for recompilation, and different people on the verification team can be completely 
insulated from one another. Each person can develop their own verification script, and 
changes to that script only affect their own simulations. 



Tel as a choice of scripting language 

30 The initial approach taken was to extend the configuration files that were 

already in use to handle simple conditional and looping constructs, and to extend the 
PLI routines that were in use to process these configuration files to become a simple 
interpreter. 
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It was decided to investigate the feasibility of using Tel as a scripting 
language (see J. Ousterhout, Tel and the Tk Toolkit , p. xvii, Addison-Wesley, (1994)). 
This turned out to be a very good idea. After many attempts to write custom 
interpreters for various tools, it was decided to write the ultimate, reusable and 
embeddable interpreter. Tel appeared to have all the characteristics that are necessary 
to implement the invention, Le. it was already developed, it was free, it was easily 
extendable, and it was easy to embed in an application. 

The obstacle 

There was a problem to overcome: 

The VERILOG language is extended through function calls. If a user needs 
new functionality, it is implemented in C, and the PLI API is used to make it available 
as a new function that can be called from VERILOG. Tel is also extended through 
function calls, but new functionality is implemented in another compiled language 
(typically C) and is linked into Tel as a new Tel function. 

A system was implemented in which the VERILOG simulation starts up a 
Tel interpreter and instructs it to run a script. This implied a PLI function call. At some 
point the Tel interpreter encounters a function that is mapped to a certain VERILOG 
task. It then must pass control back to VERILOG so that the task could be executed. 
This implies that the PLI call that invokes the interpreter must return, leaving the 
problem of how to resume execution of the Tel script after executing the VERILOG 
task. 

In addition to extending the functionality of configuration files through the 
use of a scripting language, it was necessary to invent a system through which one 
could pass control between VERILOG and Tel, through function calls on either side. In 
this way, the VERILOG code controls when Tel interpreters are invoked, but the Tel 
interpreters cause VERILOG tasks to be executed (implying that a PLI call needs to 
return), while retaining the state of the Tel interpreter so that it could resume execution 
of the Tel script after the VERILOG task completed. 

The solution 

The preferred embodiment of the invention solves this problem by 
implementing a simple client-server model, in which the Tel server runs on a separate 
thread from the VERILOG simulation. Figure 1 is a block schematic diagram that 




illustrates the required interaction between the VERILOG simulation 10 and a Tel 

interpreter 20. Synchronization between the VERILOG simulation and the Tel server is 

performed via a set of semaphores. This allows control to be passed freely between 

VERILOG and Tel. The VERILOG code determines when Tel interpreters are invoked 
5 and Tel interpreters can randomly cause VERILOG tasks to be executed. Thus, a PLI 

function call executes a Td script (100), a C function call executes a VERILOG task 

(1 10), and a PLI function call resumes script execution (120). 

The TCL_PLI library allows any number of Tel interpreters to be 

instantiated in a VERILOG simulation. Every interpreter is completely customizable. 
10 PLI functions initialize interpreters and define new Tel functions that are mapped to 

VERILOG tasks. PLI functions also start running scripts on the Tel interpreters and 

pass control between VERILOG and Tel. 

The VERILOG tasks have access to arguments passed to the Tel functions 

that invoked them, allowing information to be passed from Tel to VERILOG. The 
15 VERILOG tasks also have the ability to control the return values of their Tel 

counterparts, allowing information to be passed from VERILOG to Tel. PLI routines 

are also provided that allow direct sharing of information between Tel and VERILOG, 

as well as between different Tel interpreters. 



20 Interaction between VERILOG and Tel 

At the core of the TCL_PLI library are four PLI functions: $tcllnit, 
$tclExec, $tclGetArgs, and $tclClose. 



• $tcllnit creates and initializes a new Tel interpreter. It defines the new Tel 
25 functions that are used to invoke VERILOG tasks, maps them to specific tasks, and 
defines how many arguments they take. 



• StclExec passes control from VERILOG to the Tel server. It launches a new 
script or resumes execution of a script that was stalled when the interpreter encountered 
30 a function that was mapped to a VERILOG task. StclExec returns under one of three 
conditions: when an error occurs, when the script ends, or when a function is 
encountered that is mapped to a VERILOG task. 
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• StclGetArgs accesses the argument values that were passed to an extended Tel 
function. 

• StclCIose destroys a Tel interpreter and frees the resources with which it is 
5 associated. 

The following code segment (Table A) shows how an interpreter is created 
and initialized in VERILOG. The interpreter has three extended Tel commands 
(b_write, b_read and b_wait_irq) that are mapped to VERILOG tasks. These 
10 commands allow scripts running on the interpreter to write data on a bus, read data from 
a bus, or wait for an interrupt to occur on the bus. 

Table A 

1 parameter 
15 2 BUS.WRITE = 1, 

3 BUS_READ = 2, 

4 BUS_WAIT_IRQ =3; 

5 initial 

6 begin: processor_model 
20 7 integer tcl_handle, 

8 tcl_command, tcl_return_value; 
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9 


// Initialize interpreter that 




10 


// knows about the three 




11 


// extended Tel commands: 




12 


tcljiandle = $tcllnit ( 




13 


"processor", tcl_command, 




14 


tcl_return_value, 




15 


"b_write", BUS_WRITE, 


2, 


16 


"b_read", BUS_READ, 


1, 


17 


"b_wait_irq",BUS_WAIT_ 


IRQ,0 


18 


); 




19 


if (tcl_handle == 0) 




20 


begin 




21 


$display ("Ink error."); 






22 Sfinish; 

23 end 

On lines 1 to 4, three integer parameters are defined that represent the three 
5 extended Tel commands in VERILOG. Lines 7 and 8 define three variables that are 
used to communicate between VERILOG and Tel. tcl_handle stores the handle of this 
interpreter. Each interpreter has a unique handle. It is returned by the $tcllnit PLI 
function and is used by all other TCL_PLI functions to identify the interpreter that is 
being addressed, telecommand is used by TCL_PLI to indicate to VERILOG which 

10 extended Tel function had been encountered while executing the script. It also 

indicates the completion status of the Tel script when execution of the script ends. 
tcl_return_value is used by VERILOG to communicate the return values of tasks back 
to the calling Tel functions. 

On lines 12 to 18, the call to $tcllnit initializes the interpreter. It identifies 

15 the variables tcl_command and tcl_return_value to TCL_PLL It also defines the 

extended Tel functions b_write, b_read and b_wait_irq. $tcllnit associates an integer 
value with each extended Tel function and stores the number of arguments that each 
extended Tel function should expect. $tcllnit can take a variable number of arguments 
to allow definition of any number of extended Tel functions. 

20 The return value of $tcllnit contains the handle of the newly created Tel 

interpreter. If the value is zero, this is an indication that an error occurred while 
creating and initializing the interpreter. The test on line 19 confirms that the call to 
$tcllnit completed successfully. 

The following code segment (Table B) indicates how a script is executed on 

25 a Tel interpreter and how control is passed between VERILOG and Tel. 



Table B 



24 while ($tclExec (tcljiandle, 

30 25 "example.tcl")) 

26 begin 

27 tcl_return_value = 0; 

28 case (tcl_command) 
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29 BUS_WRITE: 

30 bus_write (tcl_handle); 

31 BUS.READ: 

32 bus_read (tcl_handle, 

33 tcl_return_value); 

34 BUS_WAIT_IRQ: 

35 bus_wait_irq; 

36 endcase 

37 end // while 

38 if (telecommand != 0) 

39 begin 

40 $display ( 

41 "Error in Tel script!"); 

42 $finish; 

43 end 

44 $tclClose (tcljiandle); 

45 end // processor_model 

When $tclExec is encountered the first time (line 24), the Tel server is idle. 
20 This is an indication that it should start executing the script "example.tcl". As 

mentioned earlier, StclExec returns under one of three conditions: if an error occurs, if 
the script ends, or if an extended Tel function is encountered. A non-zero return value 
indicates that an extended Tel function had been encountered. A return value of 0 
indicates that the script has ended or that an error occurred. In the case where an 
25 extended Tel function is encountered, the Tel interpreter stalls until the next call to 
StclExec informs it that the VERELOG task has been executed. 

The while loop (lines 24 to 37) continues looping as long as the return value 
of StclExec remains positive. This means that the simulator continues executing 
VERILOG tasks as they are encountered in the Tel script that is being executed. If 
30 StclExec is called when the Tel server is not idle, it assumes that execution of the 
current script should continue. StclExec checks that the script name passed to it 
matches the name of the script being executed and returns an error value if this is not 
the case. 
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Not all VERILOG tasks have meaningful return values. Therefore, 
tcl_return_value is initialized to zero to ensure that an undefined value is not eventually 
returned to the Tel interpreter (line 27). 

Whenever StclExec returns a non-zero value, the tcl_command variable 
5 contains the integer value corresponding to the extended Tel function that was 
encountered in the script. The case statement on line 28 calls the VERILOG task 
associated with this Tel function. 

Once the VERILOG task completes, the while loop continues with another 
call to StclExec. StclExec again returns when it encounters an extended Tel command, 
10 reaches the end of the script, or encounters an error. The result is that the while loop 
causes the whole Tel script to be executed, and VERILOG tasks are called in the order 
determined by the execution of the Tel script. 

When the while loop terminates, it is appropriate to check that no error 
occurred (line 38). When StclExec returns zero (causing the while loop to terminate), 
15 the tcl_command variable contains an exit code indicating either normal termination 
(end of script reached) or abnormal termination (due to an error in the script). 

At this point, the Tel interpreter can be deleted if it is no longer required 
(line 44). It should be noted that the same interpreter can be used repeatedly. Scripts 
can also be run on the interpreter from different points in the VERILOG code. 
20 TCL_PLI generates an error if an attempt is made to run multiple scripts on one 

interpreter simultaneously. Interpreter state information (such as variable values and 
procedure definitions) is preserved until the interpreter is destroyed through a call to 
StclClose. 

The following code segment (Table C) shows the definition of the 
25 VERILOG tasks that are called under control of the Tel interpreter. 



Table C 



49 task bus_write; 
30 50 input [31:0] tcl_handle; 

51 integer address, data; 

52 begin 

53 StclGetArgs (tcl_handle, 

54 address, V, 
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55 data, "i" 

56 ); 

57 // Simulate the write cycle 

58 // on the bus 

59 end 
60 

61 task bus_read; 

62 input [31:0] tcljiandle; 

63 output [31:0] data; 

64 integer address; 

65 begin 

66 $tclGetArgs (tcl_handle, 

67 address, "i" 

68 ); 

69 // Simulate the read cycle 

70 // on the bus 

7 1 data = data_read_from_biis; 

72 end 
73 

74 task bus_wait_irq; 

75 begin 

76 @(bus_irq); 

77 end 

A VERILOG task can gain access to the arguments of the Tel function by 
which it is invoked. For this purpose, the handle of the interpreter is passed to these 
tasks (line 50). A call to StclGetArgs is used to transfer this information from Tel to 
VERILOG (line 53). StclGetArgs can handle integer or string arguments, and performs 
the appropriate conversions. 

The bus_read VERILOG task illustrates how the return value of a Tel 
function is set up in the VERILOG task (lines 71 and 33). TCL_PLI assumes that the 
return value is an integer. The bus_wait_irq task illustrates a simple case where the Tel 
interpreter can be stalled while waiting for an event in the simulation (line 76). 
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The following (Table D) is a sample Tel script that can be run in the 
VERELOG example shown above. It illustrates how the execution order of the 
VERILOG tasks are completely controlled from Tel. In essence, the Tel script is in 
complete control of the simulation in the same way that software controls the hardware 
5 on which it is run. 

Table D 

I # Write to a register, wait 

10 2 # for an interrupt and read back 

3 # a cause: 

4 puts "$::vname @ $::vtime: \ 

5 Writing Oxaa to address 0x05:" 

6 b_write 0x05 Oxaa 

15 7 puts "$::vname @ $::vtime: \ 

8 Waiting for interrupt..." 

9 b_wait_irq 

10 puts *'$::vname @ $::vtime: \ 

I I Interrupt received" 

20 12 puts [format "Address 0x05 now \ 

13 contains %x" [b_read 0x05]] 
14 

1 5 # Write to another register, 

16 # then poll until bit 1 changes: 
25 17 puts "$::vname @ $::vtime: \ 

18 Writing Oxff to address 0x0a: M 
19b_write 0x0a Oxff 

20 set bit_l 0x0 

21 while {$bit_l} { 

30 22 # Read 0x0a and check the LSB: 

23 set bit_l \ 

24 [expr [b_read 0x0a] && 0x01] 

25 puts "$::vname @ $::vtime: \ 
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26 Bit 1 value is $bit_l M 

27 } 

28 puts "$::vname @ $::vtime: \ 

29 Value changed!" 

The variables vname and vtime are defined by the TCL_PLI library, vname 
contains the name of the interpreter (passed as the very first argument to $tcllnit). It is 
useful to determine the source of a message, vtime contains the current simulation time, 
which is very useful for tracing simulator messages back into waveforms. 



Behind the scenes 

As mentioned previously, the Tel interpreter is run on a separate thread 
from the VERILOG simulation. A call to $tcllnit causes a secondary thread to be 
created, on which the Tel server runs. The Tel server creates and initializes a new Tel 
15 interpreter, and then enters a loop in which it waits for and executes commands received 
from the PLI functions. 

The following C code segment (Table E) is a simplified version of the, 
command loop in the Tel server. 

20 Table E 

1 /* Wait for and service requests 

2 to run scripts */ 

3 runServer = 1 ; 
25 4 while (runServer) 

5 { 

6 /* Pass control to the VERILOG 

7 thread */ 

8 sem_post (&t->t2v); 

30 9 /* Wait for an instruction from 

10 the VERILOG thread */ 

11 sem_wait (&t->v2t); 

12 switch (t->serverCommand) 

13 { 

12 






14 


case TC_RUNSCRIPT: 




15 


t->serverStatus = 




16 


tclServer_runScript (t); 




17 


break; 


5 


18 


case TC_CLOSE: 




19 


run Server = 0; 




20 


t->serverStatus = TS_DONE; 




21 


break; 




22 


case TC_ADDCOMMAND: 


10 


23 


/* Add new commands to 




24 


interpreter */ 




25 


break; 




26 


case TC_LENKVARS : 




27 


/* Link with VERILOG 


15 


28 


variables */ 




29 


break; 




30 


case TC_SH ARE V ARS : 






/ L/1UK WlLIl VdJIdLJICa llUIIl 




32 


other interp */ 


20 


33 


} 




34 


} 



Once the Tel server is initialized, it enters the command loop and 
immediately posts the t2v semaphore to the PLI to indicate that it is ready to accept a 
25 command. It then waits for the v2t semaphore. Upon receipt of the v2t semaphore, it 
examines the serverCommand member of its defining structure to determine what 
command was issued and executes the command. When the command is completed, 
the loop starts again. 

On the VERILOG thread, a PLI function sends a command to the Tel server 
30 by setting up the serverCommand member of the server's defining structure and then 
posts the v2t semaphore. The PLI function then waits for the t2v semaphore as an 
indicator that control is being passed back to VERILOG. 

The following sequence takes place if the Tel script in the previous example 

is executed: 

13 




• When StclExec is called from the VERILOG simulation the first time (Tel server is 
idle), it instructs the Tel server to start executing the script, and then waits for the 
t2v semaphore. The Tel server executes lines 1 through 5 of the script. When it 

5 reaches line 6, which contains the extended command b_write, it calls the function 

tclServer_verilogCall. This function is called for all extended commands that are 
mapped to VERILOG tasks. tclServer_verilogCall saves the relevant information in 
its defining structure, posts the t2v semaphore, and then waits for the v2t 
semaphore. 

10 

• When StclExec receives the t2v semaphore, it synchronizes linked variables and 
returns to VERILOG. This allows the simulator to enter the while loop in which it 
executes the tasks associated with extended Tel functions (lines 24 to 37 of the 
VERILOG example). When the task associated with b_write completes, StclExec is 

15 again called. This time the Tel server is not idle, so $tclExec assumes that 

execution of the script should resume. It synchronizes linked variables, posts the 
v2t semaphore, and waits for the t2v semaphore. 

• tclServer_verilogCall receives the v2t semaphore and returns, allowing execution of 
20 the Tel script to continue. This process repeats itself until the script completes. 

When this happens, the Tel server indicates this to the PLI when posting the t2v 
semaphore. This time, when StclExec returns, the VERILOG while loop terminates. 

The following C code segment (Table F) shows a simplified version of 
25 tclServer_verilogCall, the function that is called by the Tel interpreter when it 
encounters an extended command. 

Table F 

30 1 int tclServer_verilogCall (...) 

2 { 

3 /* Store the command value for 

4 the VERILOG thread */ 

5 t->command Value = 

14 



6 command->value; 

7 /* Store the argument array 

8 and count in the interpreter 

9 struct to make it accessible 
5 10 to tclGetArgs: */ 

11 t->argc = argc; 

12 t->argv = argv; 

13 /* Semaphore VERILOG */ 

14 sem_post (&t->t2v); 

10 15 /* At this point control has 

16 been passed back to VERILOG, 

17 where the functionality is 

18 being simulated. Once done, 

19 the main thread will 

15 20 semaphore this thread to 

21 continue. */ 

22 /* Wait for semaphore from 

23 VERILOG */ 

24 sem_wait (&t->v2t); 

20 25 /* Set up the return value */ 

26 sprintf (message, "%d", 

27 t->retVal); 

28 Tcl_SetResult (t->interp, 

29 message, TCL_VOLATELE); 
25 30 return TCL_OK; 

31 } 

It is important to note that, even though TCL_PLI is multi-threaded, and ^ 

that every interpreter is run on a dedicated thread, the essential single threaded nature of 

VERILOG simulations is maintained. Only one call to $tclExec can be reached in the 

30 VERILOG simulation at any given time. The VERILOG simulation stalls until this call 

returns, which occurs when the Tel interpreter calls tclServer_verilogCall or when the 

script completes. tclServer_verilogCall, on its part, only returns when the next call to 

$tclExec is encountered in the VERILOG simulation. This means that, even though 

many Tel scripts may be in the process of execution at any given moment in time, only 

15 



one of them or the VERILOG code itself is running at that moment. All event 
scheduling and execution order is still under the control of the simulator. 

It should also be noted that the Tel server executes scripts in zero simulation 
time. Simulation time does not advance for the duration of a call to StclExec. 
5 Simulation time advances normally while the VERILOG tasks invoked from Tel are 
executed. 



The TCL_PLI library 

The following discussion provides a brief overview of the PLI functions 
10 available in the EFI_PLI library. The $tcllnit, StclClose, StclExec and StclGetArgs PLI 
functions have already been discussed in detail and are not listed again in this section. 



StcILinkVariables and $tclShare Variables 

StclLinkVariables allows direct sharing of variables between VERILOG and 
15 Tel. It links a list of VERILOG variables with a list of Tel variables. The TCL_PLI 
library then automatically keeps these variables synchronized until the interpreter is 
deleted. StclLinkVariables has support for integer and string variables, and can mark 
variables as read-only in the Tel interpreter, meaning that they can be modified in 
VERILOG, but not in Tel. 
20 $tclS hare Variables allows direct sharing of variables between two different 

Tel interpreters, without any connection to VERILOG. After a call to 
$tclS hare Variables, the list of Tel variables in both interpreters are automatically 
synchronized by the TCL_PLI library, until one of the interpreters is deleted. 
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^StclSetMCD and StclAddMCD 

4>tclSetMCD and StclAddMCD allow the Tel interpreter access to multi- 
channel descriptors'mJiie VERILOG simulation* This allows the user to redirect 



messages from the Tel interpreter"!! 



lies that also record messages directly from 



the simulation, which is critical for preserving thVor^er in which messages were 
generated. Any VERILOG muIti-channel\descripto>can be^associated with a Tel 
interpreter. If an interpreter has an associated MCD, its built-in puts^remmand is 
modified, causing all output to stdout to be redirected to the multi-channel d^scqptor. 
This makes it very easy to open a log file and set up an MCD that causes all messages 
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from the simulatio njboth from VERILOG and Tel ) to be printed to stdout, as well as 
a log file. ^ 

StclSetErrorReg 

5 StclSetErrorReg allows the user to identify one register in the VERILOG 

simulation that is linked to any error occurring in any interpreter or in TCL_PLI. If any 
error occurs, the value of this register is changed, allowing the simulation to react to the 
error immediately. 

10 StclWarnOnX 

As with any software language, Tel has no concept of X or Z values. The 
default behavior of TCL_PLI causes execution of the Tel script to be terminated under 
any of the following conditions: 

If the return value of an extended Tel function is X or Z, or if any linked variable is X 

15 or Z at a point where it is evaluated in the script. 

For purposes of the preferred embodiment of the invention, this is correct 
and desirable behavior. In the presently preferred embodiment of the invention, X and 
Z values should never propagate into the software domain because software can not 
handle these values. However, some users of TCL_PLI do not share this opinion, and 

20 hence the existence of StclWarnOnX. Calling StclWarnOnX causes TCL_PLI to print a 
warning message under any of the previously described conditions. Execution of the 
script continues. If the variable in question is an integer, its Tel value is considered to 
be zero. If it is a string, its Tel value is "Zz". 

Note that only a warning message is generated. In a simulation that prints 

25 many messages, this message can easily scroll off the screen before being noticed. The 
misinterpretation of the VERILOG value in Tel can ultimately cause all sorts of strange 
behavior and may cause problems the user who decides to use StclWarnOnX. 

Example: PCI_TCL 

30 The preferred embodiment of the invention includes a module that 

instantiates Synopsys LMC source models for a PCI master and a PCI slave together 

with two Tel interpreters. The tasks supplied with the PCI models are mapped to 

extended Tel functions, allowing one to execute Tel scripts that interact with other 

devices on a PCI bus. The VERILOG code causes one of the Tel interpreters to start 
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executing a script when it senses an interrupt on the PCI bus. This allows easy 
modeling of interrupt service routines written in Tel. Execution of a Tel script can be 
linked to an interrupt by waiting in the VERILOG code for the interrupt to occur before 
entering the while loop calling StclExec. 
5 The two interpreters in the PCI master have to compete for access to the 

bus. This is accomplished through a simple gating mechanism that checks whether the 
bus is busy before calling a task that starts a transaction on the bus. If the bus is busy, it 
waits for the current transaction to complete before starting the new one. This 
arrangement models actual software behavior very well, where several processes 

10 running on a CPU have to compete for access to the PCI bus, with no guarantee on the 
order in which accesses takes place. 

The PCI_TCL module allows both interpreters to load data files directly 
into the LMC slave memory (in zero simulation time). Data can also be dumped from 
the slave memory to a file. Both interpreters can execute memory or I/O transactions on 

15 the bus. Two extended Tel functions are used for bursting commands: the one executes 
the address phase of a burst while repeated calls to the other executes one data cycle per 
call. An encapsulating Tel procedure takes an address, byte count, and byte array and 
performs a corresponding burst read or write on the PCI bus by appropriately calling the 
underlying extended Tel functions. 

20 The PCI_TCL module allows extensive testing of any PCI based device 

without writing a single line of VERILOG code for the test bench. The preferred 
embodiment of the invention also comprises a library of Tel procedures that simplifies 
tasks such as configuration of PCI devices. 

25 TCL_PLI in practice 

The TCL_PLI library has been used to verify a 600k gate design and is 
currently being used on two designs, both of which are larger than one million gates. 
All of these designs are PCI based ASICs. Using the PCI_TCL module has made it 
possible to write elaborate scripts that interact with the device under test in very much 
30 the same way as software would interact with the real hardware. 

Tel interpreters were also used in modules that interact with other ports on 
the device under test. In each case, VERILOG tasks were written that know how to 
interact with a port at a low level. The higher level behavior of the test module is then 
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controlled by a Tel script. This allows one to change the behavior of test modules 
radically by running differing Tel scripts on them. 

In the presently preferred test benches, there typically is a master Tel 
interpreter that controls all test modules that interact with the device under test. It 
5 determines which Tel scripts are executed when and on what module. This approach 
provides centralized control over an extremely configurable test bench. 

Pitfalls 

There are a number of pitfalls to watch out for when using the TCL_PLI 
10 library. Most important are some issues related to the simulator. The presently 

preferred embodiment of the invention comprises use of the TCL_PLI library with 
Synopsys' VCS simulator. With VCS version 4.0.3 it was necessary to compile 
through C code. VCS allows compilation through C, assembler, or directly to object 
code. Compilation through C is the slowest, but Synopsys advises to compile through C 
15 if using multi-threaded PLI. Not doing this causes immediate core dumps, even when 
the TCL_PLI library is linked in, but not used. The presently preferred embodiment of 
the invention comprises VCS version 5.0.1. This version does allow one to compile 
directly to assembler or object code. It should also be mentioned that, other than the 
penalty of slower compile times, VCS 4.0.3 works perfectly well with TCL_PLL 
20 Following is a list of compile time options for VCS that are needed when using the 
TCL_PLI library: 

• -Xstrict: Prevents VCS from using resources that are used by the multi -threading 
library. 

25 

• -lpthread -lposix4: Link with the Posix threading support libraries. 

TCL_PLI has also been used with Cadence VERILOG-XL version 2.5. 

One of the most common problems encountered by first-time users, is that they forget to 

30 assign a default value for the return value register in the while loop that executes the Tel 

script. TCL_PLI has no way to distinguish whether a return value is used, and always 

complains if a return value is X or Z. Therefore, a default value should always be 

assigned. A problem that was anticipated, but that is not encountered frequently, is with 

Tel bugs in long running simulations. Because Tel is an interpreted language, a syntax 
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error is only detected when the interpreter encounters the statement that contains the 
error. There were concerns that a simulation could start off that would run very long, 
only to have it die near the end due to a bug in the Tel script. The way that this problem 
is presently managed is to develop scripts incrementally, thereby ensuring that long- 
5 running simulations are performed with proven Tel code. 



Conclusion 

The preferred embodiment of the invention significantly reduces time spent 
recompiling test benches. Test benches are a simpler, and consist of modular, reusable 
10 modules that are easy to maintain. New tests are implemented in new, separate scripts, 
eliminating the problem where addition of new tests causes existing tests to break. 

The Tel scripts themselves are often reusable. When module level testing is 
performed, functionality between Tel and VERILOG is partitioned such that the Tel 
scripts are reusable in system level testing. As an example, a Tel interpreter interacting 
15 with a module uses extended Tel functions that take the same arguments and return 

values as matching functions in the PCI_TCL module, even though it is not interacting 
with a PCI bus. This way, the scripts that are developed for testing the module can be 
rerun without modification in system level tests. 

In one use of the invention, it was possible to reuse a complicated Tel script 
20 written for a project that was cancelled. The module was initially written to test a 

memory controller by performing random reads and writes and automatically verifying 
data integrity. When it was later necessary to design logic that had to access system 
memory through a PCI bus, the script was reused without modification. 

Another embodiment of the invention allows the porting of Tel scripts to 
25 real hardware. This enables a verification suite to run on ASICs when they return from 
the foundry. 

Although the invention is described herein with reference to the preferred 
embodiment, one skilled in the art will readily appreciate that other applications may be 
substituted for those set forth herein without departing from the spirit and scope of the 
30 present invention. Accordingly, the invention should only be limited by the Claims 
included below. 
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